The development of application and system software for information processing systems has traditionally been a time-consuming and somewhat repetitive task, with software developers often having to write and re-write code to perform well known user interface and system functions in addition to writing the code optimized to implement the desired new functionality. Object-oriented programming (OOP) has emerged as a dominant programming paradigm that enables the rapid development and implementation of functionality while permitting the customization and re-use of software “objects”.
The power of OOP as a software development philosophy is realized chiefly through object frameworks which provide a collection of base object classes that can be selectively utilized by a system developer to create a software system, much like a hardware developer might construct a desktop computer from standard hardware components. Object frameworks are particularly advantageous when utilized within a distributed computing environment in which multiple, and possibly heterogeneous or dissimilar computer systems are interconnected to allow system hardware and software resources to be shared between computer systems. In order to permit programs written in multiple diverse languages to utilize object classes defined within a single object framework, it is necessary to develop a minimum level of object standardization to enable the inter-operability of object-oriented software. One organization that is working to establish industry guidelines and object management specifications to provide a common object framework for application development is the Object Management Group (OMG).
The specifications promulgated by the OMG enable the reusability, portability and interoperability of object-based software in heterogeneous distributed computing environments. An example of a commercially available object framework that conforms to OMG specifications is contained in the WebSphere Enterprise Edition Component Broker Version 3.0, available from International Business Machines Corporation.
The OMG is an international consortium of organizations involved in various aspects of client/server computing on heterogeneous platforms such as shown in FIG. 1. The OMG has set forth published standards by which clients communicate with objects running in servers. As part of these standards, an Object Request Broker has been defined as part of the Common Object Request Broker Architecture (CORBA). CORBA defines the object-oriented bridge between the client and the server. The object request broker (ORB) de-couples the client and server applications from the object-oriented implementation details.
The OMG defines industry standards for use in CORBA ORB environments in a document referred to as “CORBAservices: Common Object Services Specification”, which is included herein by reference. Such service specifications include, inter alia, a “Naming Service” Specification 97-12-10, “Life Cycle Service” Specification 97-12-13, and a “Query Service” Specification 97-12-18.
Objects within a CORBA ORB environment are referenced using an Interoperable Object Reference (IOR). An IOR is only understood by ORB implementations and its contents are opaque to the user of the distributed object-oriented environment. The Naming Service allows objects to be located in the distributed object-oriented environment using human understandable and readable names, by providing a means to obtain the required IOR through the use of the name. The Naming Service defines a hierarchical mechanism for naming objects, with NamingContext objects and bindings to leaf node objects, similar to directories and files in a computers file system. Again, similar to a file system, a name must be unique within a NamingContext but different NamingContexts can contain identical names. Thus, there is a concept of a simple name (within a NamingContext) and a fully qualified name that contains the complete path within the naming system.
In CORBA-compliant systems, the Query Service allows SQL query statements to be processed over queriable collection objects, where the collections are identified by a simple name in a Structured Query Language (SQL) expression. With no further qualification for finding the collection than a simple name, an implementation of a Query Service could only allow for queries over collections at some fixed location in the distributed environment. For example, the QueryEvaluator would use some predefined Naming Context in which it would locate collections by simple name (e.g. a Naming Context representing all the collections within a particular server process). However, there was a need to enable the Query Service to work for queries over collections that could be anywhere within a distributed object oriented environment, while still allowing the SQL to only contain a simple name for identifying the collection.
Within the OMG Life Cycle Services standard, a number of object-oriented programming interfaces are defined in support of the creation and destruction of objects within a heterogeneous distributed computing environment. Among the interfaces and terminology found within the OMG Life Cycle Services standard is the “FactoryFinder” interface, which provides a standard service that can be utilized by applications to locate a Factory object, i.e. an object that is used to create instances of other objects, within the heterogeneous distributed computing environment. The Life Cycle Service provides a mechanism for finding factories anywhere in a distributed environment, where the factories are identified by the interface supported by the objects which the factories create. Therefore, FactoryFinders are used to find objects by type rather than by simple or fully qualified names as is done by the Naming Service.
In many object-oriented environments, some collection objects also serve as factories for objects of the type they collect. An example of this would be the Home objects defined in the Component Broker documentation previously mentioned. Thus, Home objects, being both collections and factories, are the target objects to be found by both Query and Life Cycle Services. This introduces the idea that the Life Cycle Service might be used by the Query Service to locate collections rather than using the Naming Service. However, it must be kept in mind that there are also collections which are not homes and which must also be able to be found using the Query Service.
Thus, there is a need for an improved methodology and implementing system which enables the utilization of the Life Cycle Service for finding queriable collections, using simple collection names, in a distributed information processing environment.